Internet Protocol Multimedia Subsystem (IMS) is an architectural framework defined by the 3rd Generation Partnership Project (3GPP) for delivering Internet Protocol (IP) multimedia to user equipment (UE) of the IMS network. An IMS core network (sometimes referred to as the “IMS core”, the “Core Network (CN),” or the “IM CN Subsystem”) permits wireless and wireline devices to access IP multimedia, messaging, and voice applications and services. IMS allows for peer-to-peer communications, as well as client-to-server communications over an IP-based network.
The IMS makes use of Session Initiation Protocol (SIP)—a signaling protocol that can be used to establish, modify, and terminate multimedia sessions (e.g., a multimedia telephony call) over packet networks, and to authenticate access to IMS-based services. The IMS core network may include various nodes that are configured to utilize SIP signaling for controlling and managing multimedia sessions of the IMS core network. Such nodes are referred to herein as “SIP Servers”. FIG. 1 is a schematic diagram illustrating a portion of an example IMS network 100. The IMS network 100 is shown as including SIP servers in the form of Call Session Control Function (CSCF) nodes including an interrogating CSCF (I-CSCF) node 102 and multiple serving CSCF (S-CSCF) nodes 104(1), 104(2), . . . , 104(N) (collectively 104).
A UE may connect to the IMS network 100 through a radio access network (RAN), and may register with the IMS network 100 using a SIP REGISTER method, which is a mechanism for attaching to the IMS network 100. For simplicity, FIG. 1 illustrates a previous hop 106 to represent the node that ultimately receives the SIP REGISTER method from the UE prior its transmission to the I-CSCF node 102 along signaling path 108.
FIG. 1 further shows a home subscriber server (HSS) 110 that maintains a master database 112 containing mappings from UEs to corresponding S-CSCF nodes 104 that are designated for providing IMS-based services to the UEs. Specifically, the master database 112 of the HSS 110 may store fully qualified domain names (FQDMs) of each S-CSCF node 104 that is assigned to a UE through an IMS registration procedure. For example, if the I-CSCF node 102 selects S-CSCF node 104(1) to serve a particular UE associated with “User A”, the S-CSCF node 104(1) receives a notification of this selection from the I-CSCF node 102 via signaling path 114, and the S-CSCF node 104(1) instructs the HSS 110, via signaling path 116, to update the master database 112 with the FQDM 118 for S-CSCF node 104(1) (e.g., an FQDM 118 such as “S-CSCF-104-1.sip.operator.com”). This creates a binding between the S-CSCF node 104(1) and User A.
Once the UE of User A is registered and assigned to S-CSCF node 104(1), all SIP signaling originating and terminating at the UE of User A will be routed through S-CSCF node 104(1). Furthermore, in order to ensure that the signaling path through S-CSCF node 104(1) remains open for the entirety of User A's session (as well as other sessions of other users who are assigned to S-CSCF node 104(1)), the S-CSCF node 104(1) adds its FQDM 118 (i.e., the same FQDM 118 stored in the master database 112 of the HSS 110) in a record-route header 120 of any new SIP message receives at S-CSCF 104(1) before forwarding the SIP message to the next hop 122 via signaling path 124.
When the S-CSCF node 104(1) fails (i.e., the S-CSCF node 104(1) is rendered inoperative), any new SIP traffic received at the I-CSCF node 102 from a UE that is assigned to the S-CSCF node 104(1) will be routed to the failed node without knowledge that the S-CSCF node 104(1) has failed. This is because the I-CSCF node 102, upon receiving such new SIP traffic, will query the HSS 110 via signaling path 126 to obtain, via signaling path 128, the FQDN 118 of the S-CSCF node 104(1) assigned to the UE, and then issue a query to a domain name system (DNS) server 130 via the signaling path 132 to obtain, via signaling path 134, the IP address of the S-CSCF node 104(1) corresponding to the FQDM 118. The I-CSCF node 102 then uses the IP address it obtained from the DNS server 130 as the address where SIP traffic from the assigned UE is to be forwarded along the signaling path 114.
In the above scenario, the I-CSCF node 102, upon sending SIP traffic to the S-CSCF node 104(1), will wait a timeout period that is configurable (anywhere from 10 to 30 seconds) for a response from S-CSCF node 104(1). If no response is received within the timeout period, the I-CSCF node 102 will refresh the IMS registration (or another relevant SIP request) for User A by initiating a procedure (e.g., a “capability discovery”) to assign a different, available S-CSCF node 104 to the UE that is configured to restore User A's session and serve the UE for the remainder of the session. However, this timeout period is an undesirable amount of time to wait for session restoration, and it may cause various adverse consequences. For example, if User A is making a call and the S-CSCF node 104(1) fails, User A may not hear a ringtone for at least the timeout period. As another example, the UE associated with User A may lose its registration, and may be unaware that registration was lost, and there may be no way to notify the UE of the lost registration. This is especially true in coverage areas where a circuit switched (CS) network is unavailable, such as when the user is using Voice Over Long Term Evolution (VoLTE) to make a call in a “LTE-only” coverage area. Even when the user is not making a call, the UE carried by the user may be trying to register with the failed S-CSCF node 104(1), and this registration may be delayed by the same amount of time due to the above-mentioned timeout period for IMS restoration.